Subject: APPN DLUR-3c draft spec available

From: "Ed Tremblay (254-5515)" <[email-masked]>
Date: Thu, 3 Feb 94 15:58:54 EST

The DLUR architecture document has been updated and is available by
anonymous FTP to ibmstandards.cary.ibm.com under the name of
aiw/sig/dlur/dlur3c.psbin - the file is a PostScript file, but treat it
as binary when you get it and print it.  There are also compressed
versions of the file (aiw/sig/dlur/dlur3c.zipbin and
aiw/sig/dlur/dlur3c.exebin) as well as a BookManager version
(aiw/sig/dlur/dlur3c.bookbin).

I will make sure a copy of this draft is included in each AIW handout
binder so that you won't be required to bring a copy to the AIW.

The items added in DLUR-3c are:

** 1) added limited DLUR multi-subnet support; related impacts include:
         - requiring all EN DLURs to register their tail vectors with
           their DLUS, even if they are not in the same subnet
         - added a configuration restriction for the DLUS-DLUR path

      While DLUR/S architecture assumed all DLUR nodes would be able to
      fully support multiple subnet configurations, not all DLUR
      implementers are able to comply.  There is a requirement to allow
      limited multi-subnet support, where a DLUR could only support a
      CP-SVR pipe with a DLUS in its own subnet.  PLU-SLU sessions may
      still cross subnet boundaries when the SLU's DLUR only has limited
      multi-subnet support.  The DLUS must be aware of the DLUR's
      multi-subnet capabilities at CP-SVR pipe activation to only allow
      same-subnet CP-SVR pipes to be established with limited
      multi-subnet support DLURs.

      The changes to the architecture include:

         i) A new bit will be defined in CV X'51' for the DLUR to
            indicate its level of multi-subnet support (0 = full;
            1 = limited)

        ii) When the new bit = 1,

              a) DLUR will respond negatively to all searches for
                 DLUR-supported dependent LUs (even those with the OCR
                 bit set)

              b) DLUS will respond positively to all searches for
                 DLUR-supported dependent LUs (even those with the OCR
                 bit set)

              c) DLUS will reject any multi-subnet CP-SVR pipe
                 activation requests

       iii) EN DLURs will be required to always register their tail
            vectors with their DLUS whether or not the DLUS and DLUR
            are in the same subnets

        iv) An EBN will be required along the path between the DLUR and
            DLUS (currently an EBN is only required in the path between
            the DLUS and the PLU

** 2) added sense code for DLUR/S over TCP/IP

      A new sense code is required by DLUS for implementation of DLUR/S
      over TCP/IP.  This sense code will be used by DLUS to limit
      CPSVRMGR sessions over LEN connections to those of type TCP.
      This is not an endorsement of LEN DLURs; rather, when the NN or
      EN DLUR uses MPTN (specifically, APPC over TCP/IP), a LEN
      appearance is presented.

** 3) separated CP-SVR pipe & SSCP-PU session rejection processing

      The DLUR document assumes only one SSCP-PU session is being
      activated while the CP-SVR pipe is being activated.  So, when
      the DLUR/S capabilities mismatch is detected and the CP-SVR pipe
      must be deactivated, current architecture directs the DLUS to
      deactivate the SSCP-PU session (either by -RSP(REQACTPU),
      -RSP(ACTPU), or DACTPU); the active PU count will then go to
      zero, driving the DLUS to deactivate the CP-SVR pipe.

      The overriding assumption, however, is flawed since several
      SSCP-PU sessions could be in the process of activation before
      the mismatch is detected.  In that situation, deactivating one
      SSCP-PU session will not force the CP-SVR pipe to come down.

      Detection of a mismatch between a DLUS and a DLUR should directly
      drive CP-SVR pipe deactivation and not rely on SSCP-PU session
      deactivation to trigger pipe deactivation.

      A new section has been added to abnormal CP-SVR pipe deactivation
      to deal with the processing of DLUR/S capabilities mismatches.
      Whichever node detects the mismatch will deactivate the CP-SVR
      pipe.

      In researching this change, several new mismatches were found
      and are included in the new section, e.g., pipes between two
      DLURs or two DLUSs (see specific item on this below).

** 4) removed format field from subfield X'91' in CV X'46'
        also: - renamed DLC type SDLCLE (SDLC leased) to SDLCNS (SDLC
                non-switched) in SF X'91'
              - added SF X'92' and X'93' for INTPU

      When subfields X'91' to X'F0' were created, the goal was to use
      the same subfields for both CV X'69' (subarea) and CV X'46' (APPN)
      to carry DLC signalling information.

      Currently SF X'91' for CV X'46' contains a Format field (currently Format
      0 is only one defined) while SF X'91' for CV X'69' does not
      contain the Format Field.  The proposed solution is to eliminate
      the Format field from SF X'91' for CV X'46' so that both SF X'91'
      definitions are the same.  Consistency is important because when
      the subfield definitions differ, the Interchange Node has to
      translate from one to other as they information crosses to and
      from subarea and APPN networks.

      One of the DLC types was renamed because the term "leased" appears
      to be currently out of favor.

      The DLC signalling information subfields for internal PU have
      been added to the document.  The first DLUR implementations only
      support internal PUs.  If you plan on supporting additional DLCs,
      let me know which ones and please prioritize them too so that the
      respective subfields can be defined as needed.

** 5) corrected DLUR BIND name substitution processing

      The document description of DLUR BIND name substitution
      processing is incorrect.  It directs the DLUR to compare the URCs
      and the PLU names saved by the DLUR and received on the BIND, and
      if URCs and PLU names match, replace the BIND's PLU name with the
      saved name.

      If the names match, then there is no need to perform name
      substitution.  The function is required when the URCs match but
      the PLU names do not match; however, the current logic will not
      perform the substitution when it should.

      The BIND name substitution processing section (8.1.4) will be
      changed to read as  follows:

         * name substitution processing - the PLU name will be
           replaced as necessary, based on whether or not the saved and
           BIND's URCs match:

              - if the URCs do not match, BIND processing will continue;

              - if the URCs match, the BIND PLU name will be replaced
                with the saved PLU name, and the DLUR will discard the
                saved URC and the saved PLU name;

** 6) clarified handling DLUS-DLUS and DLUR-DLUR pipes

      The document isn't clear on how to handle a situation where a
      DLUS attempts to activate a pipe with another DLUS, or a DLUR
      with a DLUR.  It certainly could happen if the name is misdefined
      by the user.  The Locate would succeed because the partner is
      just another LU.  Subsequent CV X'51' examination would detect
      the mismatch, but I wondered whether the CV would ever get
      checked because it would arrive on an unexpected RU.  Subsequent
      investigation showed some implementers interpreted the document as
      checking the CV X'51' first and others checking the RU.

      To be consistent, and to ensure against hung pipes between like
      DLUR/S nodes, this clarification will be added:

          Upon receiving a GDS X'1500', check for a CV X'51' before
          examining the encapsulated PIU.

          During validation of a received CV X'51', if the CV indicates
          that the CP-SVR pipe partner has the same DLUR/S node type as
          this node, this node shall deactivate the CP-SVR pipe:

             - if this node is a DLUS, it will include sense code
               X'088E 0008' in the CV X'35' of the UNBIND RU

             - if this node is a DLUR, it will include sense code
               X'088E 0009' in the CV X'35' of the UNBIND RU

** 7) added EN DLUR multi-subnet impact

      While reviewing the DLUR document, Mike Evans at Data Connection
      found the following:

         There is a missing bullet in section 11.3.5.1 "DLUR/Multi-Subnet
         Impacts"

           -  A DLUR-capable End Node must set the Search Status
              Indicator in the ENCP Search Capabilities CV during the
              CP Capabilities exchange with its network node server.

         An End Node may choose not to set this indicator if it
         registers all LUs with its NNS (this significantly cuts down
         domain broadcast traffic).  CM/2 takes this approach, as does
         SNAP APPN (I can't speak for other implementations).

         An End Node cannot register its DLUS-owned LUs with the NNS,
         since the NNS will delete the directory entry as soon as the EN
         rejects a Locate (which it must do if the OCS bit is not set).
         Even if a DLUR-capable EN registers all its non-DLUS owned LUs,
         it must still set the Search Status Indicator.

      The bullet has been added, the only change being the name of the
      CV (actually ENCP Search Control (X'33')).

** 8) included ACTLU CV X'0E' in open DLUR/S formats

      There was an item in DLUR-3b ("revised formats appendix") which
      was included to move licensed formats used by DLUR/S to the open
      formats document.

      A new mismatch was discovered, falling into one of the previous
      categories:

        d) the following RUs and CVs appear in the open formats but not
           in the appendix; licensed material is used by DLUR/S
           (these will be added to the appendix and updated in the
           open formats):

            CV 0C
      --->  ACTLU  (specifically CV X'0E' in the RU)

** 9) made use of LU 6.2 BIS protocols optional for CP-SVR pipe

      The document currently requires the use of LU 6.2 BIS protocols
      on the CP-SVR pipe.  This was not a concern when the DLUS
      performed almost all CP-SVR pipe deactivation, since VTAM uses
      BIS protocols.  However, with new items 3) and 6), the DLUR will
      more frequently deactivate the pipe.  Several DLUR implementations
      do not use BIS protocols and have requested that the use of BIS
      protocols on the CP-SVR pipe be made optional.

      (Subsequently additional reasons for requiring BIS have been
       advanced, and this subject may be a good one to discuss at the
       SIG meeting.)

I'm requesting electronic comments on these items to be received no
later than February 11 (I'll be in Anaheim starting February 13).
Otherwise, bring any comments to the AIW SIG meeting. I will request
AD status for all of the items for which there is a consensus for
approval at AIW4 on February 18.

The internals chapter got a very late start (the volume of changes has
kept me busy); there will be a status report on the document changes
for AP status at the SIG meeting.  Plans are currently for an electronic
request for AP status prior to AIW5 whenever the chapter is ready.

Ed Tremblay